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© Verfahren fur die automatische Syntaxanalyse (Parsen) des Textes von Computer-Programmen in 
Kompilierern. 



© Zur Ermittiung und Darstellung der Struktur von 
Programmer die wre in C Praprozessor-Anweisun- 
gen und Erweiterungen gegenuber der abstrakten 
Syntaxbaum-Darstellung aufweisen, wird ein modifi- 
zierter Parser-Generator mil zugehoriger Parser- Ver- 
waltung verwendet, wobei mehrere Parser-Prozedu- 
ren denselben Eingabestrom vom Token verarbeiten 
und zusaizliche Operationen zum Abspalten neuer 
Parserprozeduren und zum Zusammenfuhren von 
aufgespaltenen Parser-Prozeduren sowie zum Aus- 
tausch einer Parser-Prozedur fur den einen Zweig 



FIG2 



einer bedingten Kompilierungsanweisung durch die 
Parser-Prozeduren fur den anderen Verzweigungs- 
pfad beim Auftreten von vorgegebenen bedingten 
Kompiiierungsanweisungen ausgefiihrl werden. Wel- 
che der Parser-Prozeduren jeweils durch dsn Pars- 
ergenerator laufen soil, besstimmr. die Parserverwal- 
fung, wobei der jeweilige Statur der ein^elnen 
Parser-Prozeduren in der Parserverwaltung iestge- 
halten wird- 
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VERFAHREN FUR DIE AUTOMATISCHE SYNTAX AN ALYS E (PARSEN) DES TEXTES VON COMPUTER- 
PROGRAMMEN IN KOMPILIERERN 



Die vorliegende Erfindung bezieht sich ganz 
aSlgemein auf die automatische Syntaxanalyse von 
Programmen: das Parsen und die Darstellunn. von 
Computsr-Programmen. 

Fur die Umwandlung von Quellprogtammen in 
einer symbolischen Programmsprache in entspre- 
chende Zielprogramme einer gewunschlen Maschi- 
nensprache werden Kompilierer verwendet, die zu- 
nachst das Quellprogramm analysieren und dann 
das entsprechende Zielprogramm erstellen. Im 
Rahmen der Quellprogrammanalyse ist u.a. eine 
Syntaxanalyse durchzufiihren, urn die Struktur des 
Queliprogramms richtig zu ermitteln und urn das 
Quellprogramm strukturiert fur die Weitetverarbei- 
tung darzustellen, wozu sogenannte Parser verwen- 
det werden, man siehe z.B. Jean Paul Tremblay 
und Paul G. Sorenson: "The Theory and Practice 
of Compiler Writing", Mc Graw - Hill Book Compa- 
ny. 1985. 

Die vorliegende Erfindung ist vor allem dann 
sehr nutziich. wenn die Programmiersprache einen 
relativ lose integrierten Makro-Praprozessor auf- 
weist. Obwoh! die Erfindung nicht auf eine be- 
stimmte Sprache beschrankt ist, empfiehlt sich fur 
die vorliegende Eriauterung des Verfahrens die 
Verwendung der Programmiersprache C als Bei- 
spiel einer Sprache, die einen nur wenig integrier- 
ten Makro-Praprozessor besitzt - man siehe z.B. 
Computer Language (USA), Vol. 5, July 1988, Sei- 
ten 49 bis 54. 

Ein bekannter Nachteil der Programmierspra- 
che C ist die Tatsache, daf3 der Makro-Praprozes- 
sor nur sehr wenig mif der Grammatik von C zu tun 
hat. Dadurch ergeben sich eine Vielzahl an Proble- 
men fur Programmierwerkzeuge in C, zum Beispiel 
Struktur-Editoren, bildschirmorientierte Programm- 
Browser, oder Werkzeuge zur Programmumwand- 
lung, in denen die Syntax und Semantik der Pra 
prozessor-Anweisungen zusammen mit der zugrun- 
de liegenden Programmstruktur berucksichtigt wer- 
den soil, 

Programmdatenbanken, wie sie in integrierten 
Programmierumgebungen Verwendung finden, 
mussen aile Ausgangsinformationen eines Pro- 
grammtexts enthalten, damit den Prog ram mierern 
alle strukturellen Informationen zur Verfugung sie- 
hen. In vielen dieser Umgebungen werden Syntax 
und Semantik der Programme haufig in Form von 
abstrakten Syntaxbaumen dargestellt. Abstrakte 
Syntaxbaume sind leicht zu erzeugen und zu bear- 
beiten. Zudem erlauben sie eine brauchbare Wie- 
dergabe der Programmstruktur. Fur die Darstellung 
von Programmen in der Sprache C sind abstrakte 
Syntaxbaume jedoch nicht ausreichend. Der C-Pra- 



prozessor (cpp) unterstuizt durch die bedtngie 
Kompilierung und die Makrosubstitution Eigen- 
schaften, die mit einer Baumstruktur nicht beschrie- 
ben werden konnen und auf vorhandene Parser- 

s Methoden nicht anwendbar sind. Zum Beispiel 
stellt bereits ein Programm mit einer einzigen #if- 
Anweisung im Grunde genommen zwei Programme 
dar: ein Programm, in dem der Ausdruck der Be- 
dingung zutrifft, und ein weiteres Programm, in 

io dem der Ausdruck nicht zutrifft. Viele Informationen 
werden durch den Einsatz von cpp entfeint. auf die 
der Parser spater nicht mehr zuruckschliessen 
kann. Aber auch wenn der Parser auf diese Infor- 
mationen zuriickgreifen konnte. ware es sehr 

J5 schwierig, diese beiden Aspekte des Programms in 
einem abstrakten Syntaxbaum darzustellen, Es ist 
demnach ein "Wald" von Syntaxbaumen zur voll- 
standigen Darstellung erforderiich: ein absfcakter 
Syntaxgraph. Bei den meisten C-Compilern und 

so deren Hilfsprogrammen werden die Programme zu- 
erst mit einem Makro-Praprozessor verarbeitet. Der 
daraus erzeugte Text wird anschliefiend in einer 
lexikalischen und syntaktischen Analysi itei r- 
arbeitet. In vieler Hinsicht hat der C-Praprozessor 

as sehr viel dazu beigefragen, dafi C als Sysiempro- 
grammiersprache so leistungsfahig ist. Die folgen- 
de kommentierte Aufstellung der Pra'prozessor-An- 
weisungen verdeutlicht die Starken des Praprczes- 
sors und zeigt einige der Schwierigkeiten in der 

30 Anwendung auf: 

#def ine name token-string 

ersetzt nachfolgende Stellen von Name durch 

Token-String. 

^define name (arg [, arg] token-string 
35 definiert ein parameirisieries Makro. Makrodefi- 
nitionen bestehen aus einem Makrobiock, auf 
die optional formate Parameter folgen konnen. 
Die Definition eines Makrobiocks ist eine beliebi- 
ge Folge von Token, innerhalb des Makrobiocks 
40 werden die Parameter bei der Verwendung des 
Makros an Ort und Stelie durch die im Aufruf 
des Makros angegebenen Argurnente ersetzt. 
^include "file name" 

fiigt den Inhalt einer Daiei in eine andere Datei 
-.'5 ein. Diese Anweisung wird moistens zur Qber- 
nahme der Schnittsteliendefinitionen anderer 
Module verwendet. 
m c onstant-expression 

schiieif bestimmte Textteile einer Quelldatet 
so wahlweise ein oder aus. Die #if-Anweisung wer- 
tet den Konstantenausdruck aus und libernimmt 
den Text, der vor der zugehorigen #else-, #elif- 
oder #endif-Anweisung steht, falis der Ausdruck 
zutrifft. Durch diese Moglichkeit lassen sich Mo- 
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dule erstelien, die uber verschiedene Betriebs- 
systemumgebungen und Rechnerarchitekturen 
portiert werden konnen. Diese Eigenschafl er- 
laubt auBerdem die bedingie Ubemahme ver- 
schiedener Eigenschaften in einem Modui. 
#ifdef name 

ist eine ahniiche Anweisung wie #if, mit dem 
Unterschied, daB der Text, der zwischen der 
nachsten #else-, #elif- Oder #endif-Anweisung 
liegt, nur dann aufgenommen wird, wenn name 
definiert ist. 

Die Integration des Praprozessors in die Phase 
der Syntaxanaly se wirft verschiedene Probleme 
auf. Zum Beispiel ist die Grammatik des Prapro- 
zessors nicht auf die Grammatik von C abge- 
stimmt. Da die Praprozessor-Anweisungen an jeder 
beliebigen Steile zwischen den Programm-Token 
von C stehen konnen, lassen sich die beiden 
Grammatiken nicht miteinander verknupfen. Zudom 
fiihren Anweisungen zur bedingten Kompilierung 
zwangslaufig zu mehreren Parserbaumen odor Ver- 
sionen fur ein und dasselbe Modul. Idealorweiso 
sollten die syntaktischen und semantischen infor- 
mationen dieser dadurch hervorgerufenen Versio- 
nen als integrierte Programmstruktur dargestelit 
werden. in einer iniegrierten Darstellung der Pro- 
grammstruktur sollten Makros zum einen einfach 
als Makros, ahnlich der Syntax von Bezeichnern 
oder Funktionsaufrufen, zum anderen aber auch in 
ihren erweiterten Formen zuganglich sein. Eine 
weitere Schwierigkeii ergibt sich dadurch, daB der 
Inhalt einer Makrodefinition keine abgeschiossene 
syntaktische Einheit der zugrundeliegenden C- 
Grammatik sein muB. Eine syntaktische Einheit 
kann also auch auf mehrere Dateien verteilt sein. 

Im Zusammenhang mit der voriiegenden Erfin- 
dung ermoglicht ein modifizierter Parser-Generator 
die Analyse von Programmen, die wie C-Program- 
me Praprozessor-Anweisungen enthalten und Er- 
weiterungen gegenuber der Darstellung in einem 
abstraktsn Syntaxbaum umfassen, damit eine inte- 
grierte Darstellung der Programmstruktur mogiich 
wird. 

Im Rahmen der Erfindung wird der Parser-Genera- 
tor da2u verwendet, einen Parser fur Programmier- 
sprachen zu erzeugen, die wie C Praprozessor- 
Anweisungen enthalten. Die Erweiterungen gegen- 
iiber der normalen Darstellung von Programmen 
mit einem Syntaxbaum werden auBerdem dazu 
verwendet, eine integrierte Darstellung der Struktur 
anzulegen. 

Gemafl der Erfindung umfaBt das Verfahren fur 
die automatische Syntaxanalyse eines Computer- 
Programmtextes, in dem bedingte Kompilierungs- 
anweisungen enthalten sind, durch die sich mehre- 
re Versionen eines Programms aus einem einzigen 
Quelitext ergeben, folgende Verfahrensschritte: 
* Multiplexen und Synchronisieren mehrerer 



gletchzeitig aktiver Parsei-Prozeduren, die ei- 
nen gemeinsamen Eingabestrom des Textes 
bearbeiten; 

" Abspalten einer neuen Parser-Prozedur beim 
5 Auftreten von bedingten Kompilierungsanwei- 

sungen im Eingabestrom, die darauf hinwei- 
sen, da/3 direkt nachfofgende Eingaben eine 
Variante aus einer Vielfachheit von moglichen 
Program mvarianten darstellen. als ParseFork- 
10 Operation; 

* Austausch einer Parser-Prozedur, die einem 
Verzweigungspfad der bedingten Compilie- 
rungsanweisung zugeordnet ist, durch die 
Parser-Prozedur des anderen Verzweigungs- 
»s pfads der bedingten Kompiliarungsanweisung 

als Pa rseExchange -Operation; 
" Zusammenfuhren von zwei zuvor aufgcspal- 
tonon Parser-Prozeduren, falls alle Kntenen 
fur eine Zusammenfuhrung erfLilit sind. als 
20 ParseJom-Operation. sowie 

' Festlegen der Reihenfolge der Shift- 
Reduktions-Operationen in den miteinander 
synchromsierten Parser-Prozeduren. 
Weiterbiidungen dieses Verfahrens bezughch 
25 der Steuerung der Abspaltung einer Parser-Proze- 
dur, der Durchfuhrung von Reduktionen. der Zu- 
sammenfuhrung von aufgespaltenen Parser-Proze- 
duren sowie des gesamten Verfanrensablaufes er- 
geben sich aus den weiteren Anspruchen. 
30 Die Funktionsweise der Erfindung wird nachfol- 

gend anhand eines in der Zeichnung dargesteliten 
Ausfiihrungsbeispieles erlautert 

FIG 1 zeigt einen Ausschnift aus emem 0- 
Programm mit einer bedingten Kompi- 
35 iierung und dem entsprecfienden ab- 

strakten Syntaxbaum. der sich ergibt. 
wenn das Praprozessor-Symbol CON- 
TROL definiert ist (linker Tail) und 
wenn es nicht definiert ist (rechter 
4c Teil), und 

FIG 2 stellt den abstrakten Syntaxgraphen 

fur das Beispiel in FIG 1 dar. 
An der Zeichnung kann man erkennen. dafi 
durch die Tatsache, daB sich durch bedingte Kom- 
45 pilierungsanweisungen mehrere Versionen aus ei- 
nem Programmmodul ergeben, Methoden erforder- 
lich sind, mit denen mehrere Versionen eines Pro- 
gramms von einem Parser analysiert und die em- 
zelnen Versionen zusammen in einer Struktur dar- 
50 gesteiit werden konnen. 

Fur die Ausfuhrung der voriiegenden Erfin- 
dung. ist ein LALR-Modul besonders geeignet, und 
zwar wegen der Allgemeinheit des Shift-Redukticn- 
Parser-Modelis. wegen der ausgereiften C-Tools. 
55 die mit Parser- Gen eratoren, wie YACC und Bison 
erstellt wurden, wegen der Anforderung, daB diese 
Tools die- Praprozessor-Anweisungen verarbeiten, 
sowie wegen der Umgebung, in der sich der analy- 
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sierte Code befindet, der eine saubsr getrennte 
Losung ermoglichte. 

Urn die bedingte Kompilierung im aktuellen 
Modelf zu verarbeiten, wird ein veranderter LALR- 
Parser-Treiber verwendet, damit die gteichzeitig 
synchron erfoigende Analyse eines einzigen Einga- 
bestroms von Token durchgefuhrt warden kann. 
Das erweiterte Parser-Modelt umfaBt die folgenden 
drei Operationen, die jeweils mit einer anwen- 
dungsspezifischen Rucksprung-Routtne verbundcn 
sind und zum Erstellen der abstrakten Syntaxgra- 
phen verwendet werden. 

ParseFork: spaltet eine neue Parser-Prozedur 
ab, wenn eine Anweisung wie #ifdef, #ifndef 
Oder #if im Eingabestrom angetroffen wird. 
Wahrend der Abspalturig wird der aktuelie Zu- 
siand des Parsers kopiert Dazu zahlen der 
Status-Stack und der Werte-Stack. Der Zeiger 
auf dsn Eingabestrom wird von alien Parser- 
Prozeduren gemeinsam verwendet. 
ParseJoin: versucht eine Zusammenfuhrung 
von zwei Parser-Prozeduren, wenn eine #endif- 
Anweisung im Eingabestrom angetroffen wird. 
Die beiden Verzweigungen einer Parser-Proze- 
dur konnen nichi immer sofort zusammenge- 
fuhrt werden, da die Parser-Prozeduren unter 
Umstanden die Kritierien Fur eine Zusammen- 
fuhrung nicht erfullen. Deshalb wird die Zusam- 
menfuhrung der beiden Parser-Prozeduren so- 
lange verschoben, bis beide Parser-Prozeduren 
alls Kriterien fur die Zusammeii-fuhrung erfiilien. 
Wenn Parser-Prozeduren fur eine Zusammen- 
fuhrung anstehen, bleiben mehrere Parser-Pro- 
zeduren aktiv (lesen also auch weiterhin den 
Eingabestrom), bis die beiden Parser-Prozedu- 
ren zusammengefuhrt werden konnen. Die 
Rucksprung-Rouiine wird in diesem Fall erst 
zum Zeitpunkt der Zusammenfuhrung aufgeru- 
fen. Die Verschiebung der Zusammenfuhrung 
der Parser-Prozeduren ist eines der schwierig- 
sten Probleme, die sich stelien, was nachfol- 
gend ausfuhrlich besprochen wird. 
ParseExchange: tauscht zwei Verzweigungen 
einer aufgespaitenen Parser-Prozedur aus. Dio- 
se Operation wird vorgenommen, wonn oine An- 
weisung wie #eise oder #elif im Eingabestrom 
als Token angetroffen wird. Die aktueil ausge- 
fiihrte Parser-Prozedur wird ausgesetzt und die 
zu diesem Zeitpunkt ausgesetzten Parser-Proze- 
duren werden nach einer #else- oder #elif-An- 
weisung aktiviert und fur die Aufnahme von To- 
ken vorbereitet. 
Der Parser-Algorithm us ist eine dahingehende 
Abwandlung des standardma/3igen LALR-Algorith- 
mus, einen einzigen Eingabestrom in mehreren 
Parser-Prozeduren verarbeiten zu konnen. Der 
nachstehend angegebene Algoriihmus besteht aus 
zwei Prozeduren: einer Parser-Verwaltung und ei- 



nem modifizierfen LALR-Treiber. 

Die Parser-VerwaStung multiplext den Eingabe- 
strom und bestimrrtt welche Parser-Prozedur durc'n 
den LALR-Treiber laufen soil. Der Status der ein- 
5 zelnen Parser-Prozeduren wird in einer Status-Vari- 
ablen in der Parser-Verwaltung fesigehalten. Dei- 
Status kann folgende Einstellungen haben: 

Active gibt an, da/J die Parser-Prozedur das 
aktuelie Token aus dem Eingabestrom entge- 
io gennehmen darf. 

BlockedOnlnput gibt an, dae das aktuelie To- 
ken von der Parser-Prozedur bereits erkannt 
wurde und keine weiteren Operationen durchge- 
fuhrt werden konnen, da die anderen aktiven 
is Parser-Prozeduren bereits darauf warten, das 
aktuelie Token zu verarbeiten. 
Sleeping gibt an, da/J eine Parser-Prozedur 
ausgesetzt wurde, da sie nichts mit dem aktuel- 
len Eingabestrom zu tun hat. Dies© Situation iritt 
so dann ein, wenn eine Verzweigung einer beding- 
ten Compilierungsanweisung verarbeitet wird 
und die andere Verzweigung auf die entspre- 
chende #else- oder #endif-Anweisung wariet. 
Ein wesentiicher Bestandteil der Parser-Verwal- 
25 tung und des modifizierten LALR-Treibers ist der 
Mechanismus und die Bedingungen fur die Zusam- 
menfuhrung der aufgespaitenen Parser-Prozedur. 
An jeder Verzweigungsstelle wird ein Zeiger auf die 
Spitze des Status-Stacks rniigefuhrt. Dieser Zeiger 
so zeigt auf den letzten Status, den die beiden Parser- 
Prozeduren vor der Aufspaltung gemein hatten. 
Wenn also an einer Stella, an der noch die Verar- 
beitung einer #endif-Anweisung oder eine Zusam- 
menfuhrung ansteht, eine Reduktion durchgefuhrt 
35 wird, die dazu fuhrt, da/3 der Status-Stack unter die 
Stelle mit der Verzweigung rutscht, mu/3 der Zeiger 
angepaGt werden, um auf die nachste Steile zu 
verweisen, an der die beiden Parser-Prozeduren 
wieder zusammengefuhrt werden konnten, Fiir dic- 
■10 se Zeiger wird ein Stack verwendet, um Ver- 
schachteiungen von bedingten Kornpiiierungsan- 
weisungen verarbeiten zu konnen. 

Fur eine geordnete Zusammenfuhrung mussen 
eine Reihe von Kriterien erfullt sein. Jede Parser- 
's Prozedur hat einen Status-Stack und einen Werto- 
Stack, die von Aktionsroutinen verwendet werden 
und aufeinander abgestirnmt sind. Zwei Parser- 
Prozeduren lassen sich dann sicher zusammenfuh- 
ren, wenn keine Informationen bei der Zusammen- 
so fuhrung verlorengehen konnen. Das bedeutet, dafi 
die beiden Parser-Prozeduren zusammengefuhrt 
werden konnen, wenn sie den gleichen Status- 
Stack besitzen und durch die Zusammenfuhrung 
keine Werte auf dem Worte-Stack verlorengehen. 
55 Die Kriterien fiir eine sichere Zusammenfuh- 

rung iauten: p und p' seien zwei aufgespaltene 
Parser-Prozeduren. f und f sind Zeiger auf die 
oberste Position des Status-Stacks, cler in beiden 
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Parser-Prozeduren gemeinsam vorkommt. t und f 
sind Zeiger auf die aktuellen Zeiger der jewetiigen 
Spitze des Status-Stacks. Schliefllich sei Si, s 2 ... 
si ... s, der eine Status-Stack, wahrend s'i, s'2 ... 
sV ... s'f den anderen Status-Stack beschreibt vi, 
V2 ... v f ... v, ist der eine Werte-Stack und v'i, v' 2 ... 
v'r ... v'c der andere. v' 2 ... v' r ... v' r der andere. 

Wenn folgende Bedingungen erfullt sind, kon- 
nen die beiden Parser-Prozeduren zusarnmenge- 
fuhrt werden: 

1 . Die zugehorige #endif-Anweisung wurde ver- 
arbeitet. 

2. f = f 

3. s ( *i = s'cm 

4. t = f + 1 

5. t' = V + 1 

Ein informeller Beweis fur diese Angaben ware: 
Punkt 1 ist per Definition erforderlich. 

Punkt 2 und Punkt 3 stellen sicher, da/3 die 
beiden Parser-Prozeduren vom Anfang des Stacks 
bis zur Stelle Si und s' r ideniisch sind Da2u erin- 
nert sei, da/3 f und f immer auf die hochste Posi- 
tion auf dem Stack zeigen, bis zv der die beiden 
Parser-Prozeduren gleich sind. Diese Invariante 
wird wahrend der gesamten Zeitdauer einer aufge- 
spaltcnon Parser-Prozedur beibehalten, indem f 
zum Zeitpunkt der Aufspaltung auf den Wert t 
gesetzt wird. Es kann sein, da/3 f sofort nach der 
DurchfUhrung einer Reduktiort in beiden Parser- 
Prozeduren auf t-1 gesetzt werden mu/3. Demzufoi- 
ge sind beide Stacks in den Positionen 1 ... f + 1 
identisch. Da die beiden Pa.-ser-Pro^eduren darauf- 
htn einen gemeinsarnen Eingabestrom verarbeiten, 
weisen sie im weiteren Verlauf dieselben Zustande 
auf. 

Punkt 4 und 5 garantieren, da/3 oberhalb des 
gemeinsarnen Anteiis ein Wert auf dem Werte- 
Stack steht. Da eine Zusammenfuhrung riurch eine 
Verschmelzung dieser beiden Werte zu einem ge- 
meinsarnen Wert erzeugt wird, gehen keine Inror- 
mationen verloren. 

Die obigen Bedingungen sind hinreichend. Es 
wird daruber hinaus angenommen, da/3 sie notwen- 
drg sind. 

Die Verarbeitungsschritte lauten: 

1 . Aniegen einer ersten Parser-Prozedur und 
deren Status auf BlockedOnlnput setzen. 

2. Soiange weitere Parser-Prozeduren vorhan- 
den sind: 

(a) Wenn keine Parser-Prozedur mehr aktiv 
ist (d.h. alle Parser-Prozeduren haben das 
aktuelle Token gepruft), wird das nachste To- 
ken eingelesen und alle Parser-Prozeduren, 
die sich im Status BiockOnlnput befinden, 
werden auf den Status Active gesetzt. 

(b) Soiange das aktuelle Token eine 
Praprozessor-Anweisung ist: 

i. Wenn das aktuelle Token erne #if-, 



#ifdef- Oder #ifndef-Anwoisung ist, wird 
die aktuelle Spitzc des Status-Stacks fur 
jede aktive Parser-Prozedur aufgezcichnet. 
indem ein Zeiger auf die aktuelio Spitze 

5 des Status-Stacks auf den ForkPtrStack 

gelegt wird. Damit kann spater fcstgostoflt 
werden, wann sich die beiden Parser-Pro- 
zeduren wieder zusammenfuhren lassen. 
Die Parser-Prozeduren werden anschlies- 

10 send kopiert und die kopierten Parser-Pro- 

zeduren werden in don Zusiand Sleeping 
gesetzt. 

ii. Wenn das aktuelle Token erne #eise- 
Anweisung ist, wird die Operation ForkEx- 

js change aufgerufen. Aktive Parser-PFozetiu- 

ren werden ausgesetzt, und die Parser- 
Prozeduren, die bei dieser #else-Anwei- 
sung ausgesetzt waren, werden aktiviert- 
iif. Wenn es sich beim aktuellen Token um 

20 eine #endif-Anweisung handelt. werden 

alle Parser-Prozeduren aktiviert. die bei 
dieser #endif-Anweisung ausgesetzt wa- 
ren. Anschltefiend wird versucht, die bei- 
den zuvor getrennten Parser-Prozeduren 

25 wieder miteinander zu verbmrien. Die bei- 

den Parser-Prozeduren konnen miteinan- 
der verbunden werden, wenn die Kritenen 
fur eine sichere Zusammenfuhrung erfullt 
sind. Falls die beiden Parser-Prozeduren 

-so nicht zusammengefUhrt werden konnen. 

da sie in unterschiedlichen Konfigurationen 
vorhegen. vermerkt die Parser-Verwaltung, 
da/3 eine Zusammenfuhrung often ist. Falls 
die Zusammenfuhrung stattfmdet, wird ein 

35 Wert vom ForkPtrStack entfernt und eine 

der beiden Parser-Prozeduren wird been- 
det. 

iv. Nachstes Token einlesen. 
(c) AbschlieBend wahlt die Parser-Verwaltung 
40 die aktive Parser-Prozedur mit dem hochsten 

Status-Stack aus und fuhrt die ausgewahlte 
Parser-Prozedur durch einen Iterationszyklus 
des LALR-Treibers. 
Das Ziel in Schritt 2c ist die Zusammenfuhrung 
45 zweier Parser-Prozeduren, um die durch eine be- 
dmgte Kompiiierungsanweisung verursachten Un- 
terschiede zwischen zwei Parser-Prozeduren so 
gering wie mogiich zu halten. Da sich eine Parser- 
Prozedur in einem Zustand befinden kann. in dem 
50 sie nicht mehr aufeinanderfolgend reduzsert werden 
kann, ohne dafi zwischendurch ein Shift erfolgt, 
mu/J man darauf achten, da/J die Reduktionsopera- 
tionen in den Parser-Prozeduren m einer heuri- 
stisch festzustellenden Reshenfolge abgesetzt wer- 
55 den, damit die Zusammenfuhrung so fruh wie 
mogiich vorgenommen werden kann. Diese heun- 
stische Methode. die fur die Beispielausfuhrung mit 
der C-Grammatik sehr gut funktioniert, wahlt die 
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Parser- Prozedur mit dem hochsten Status-Stack 
aus. Wenn die beiden Status-Stacks gleich hoch 
sind, wird die Parser-Prozedur ausgewahli, deren 
Bearbeitung am weitesten zuriickliegt. Diese Stra- 
tegic sorgt dafur, da/3 die Status-Stacks der ausge- 
wahlten Parser-Prozeduren naher an das Niveau 
der anderen aktiven Parser-Prozeduren heranruk- 
ken und somit keine Planung des Reduktionsab- 
laufs erforderiich ist, wie dies zum Ermitteln fur 
eine optimale Reduktionsstrategie erforderiich ist. 

Der modifizierte LALR-Treiber 
Diese Prozedur wird von der Parser-Verwaltung 
aufgerufen, urn die ausgewahlte Parser-Prozedur in 
einem Shift-Reduktions-Schritt zu verarbeiten. Der 
LALR-Treiber wurde von Aho, Sethi und Ullman, 
Compilers: Principles, Techniques, and Tools , 
Addison-Wesiey, Reading, MA. 1986, ubemom- 
men. Der modifizierte Treiber unterscheidet sich 
von diesem dadurch, da/3 der Status-Stack nur Zu- 
siande enlhalt und er nur auf die aktueil ausge- 
v/ahlte Parser-Prozedur angewendet wird. Der Al- 
gorithmus lautet: 

1. Wenn action[CurState,token] = shift s, s auf 
den Status-Stack legen und den Status von Acti- 
ve in BlockedOnfnput umwandeln. 
27 Wenn action[Cu7state,token] = reduce A -> 
j3, dann reduce A -> 6. Die Reduktion wurde 
geringfugig modifTzieit, urn mehrere Parser-Pro- 
zeduren mrteinander zu verbinden: 

(a) Bei jedem Qrammatiksymbol im String R 
wird ein Element vom Status-Stack genom- 
men. 

(b) Wenn eine Parser-Zusammenfuhrung an- 
steht und die Ho he des Status-Stack unter- 
halb des Wertes liegt, der an der Spitze von 
ForkPtrStack liegt, wird der Zeiger angepaflt, 
der an der Spitze von ForkPtrStack liegt, urn 
auf den aktuelien Status-Stack zu verweisen. 

(c) Wenn eine Parser-Zusammenfuhrung an- 
steht und die beiden Parscr-Pro2cduren die 
Kriterien fur eine sichere Zusammenfuhrung 
erfullen, werden sie zusammengefuhrt So- 
bald die Zusammenfuhrung abgeschlossen 
ist, wird der oberste Wert von ForkPtrStack 
geholt. 

(d) CurState auf Goto[CurState,A] setzen und 
CurState auf den Status-Stack legen. 

3. Wenn action[CurState,token] = accept, ist die 
Parser-Prozedur abgeschlossen. 

4. Wenn action[CurState,tokenj = error , wird die 
Parser-Prozedur verworfen. 

Die Darsteliung echter C-Programme 
Mil dem Parsen von C-Programmen unter Erhalt 
der Praprozessor-lnformationen hat man nur die 
HSIfte des Problems gelost. Die andere Halfte der 
Aufgabe ist die Darsteilung dieser Informationen in 
einem abstrakten Syntaxbaum. Der schwierigste 
Punkt betrifft die Probleme durch dio bedingte 



Kompilierung, Wie in FIG 1 gezeigt, ergeben sich 
durch die bedingte Kompilierung mehrere Versio- 
nen eines Programms aus einem Quelltext Ein 
einfacher Ansatz zur Darsteilung dieser verschiede- 

5 nen Versionen ware die Etnfuhrung einos Knotens 
im abstrakten Syntaxbaum, der den bedingt kompi- 
lierten Code darstellt. Dieser Knoten halte zwei 
weitere Unterbfiume als Nachfolger, jeweils einen 
Unterbaum fur jede Alternative einer #ifc!ef-Anwei- 

10 sung. Diese UnterbSume wiirden durch die aufge- 
spaltenen Parser-Prozeduren erzeugt und durch 
eine ParseJoin-Operation wurde der Knoten uber 
einen Verbindungsknoten Join mit seinen Machfol- 
gern verbunden. Dies ist jedoch nicht so einfach, 

75 wie es scheint. Es ergeben sich iolgende Proble- 
me: 

* Da ein LALR-Parser verwendet wird, konnen 
Reduktionen und die damii verbundenen Ak- 
tionen nur Bottom-Up (nach Analyse aller 

20 Syntax-Details) durchgefuhrl werden, so dafi 

sich eine Parser-Prozedur mit einer rechts- 
orientierten Ableitung in umgekehrter Reihen- 
folge ergibt. Moch problematischer wird die 
Angelegenheit dadurch, dafi die tmplementie- 

25 rung »links-rekursive'< Qrammatikregcfn be- 

giinstigt. Zum Beispiel: 
list : item 

list 7 item 



Dies wird zu einem Problem, wenn wir 
versuchen, Baume mit gemeinsamen Vorfah- 
ren mrteinander zu verknupfen. Wenn zum 
Beispiel in einer Anwoisungsfolgo mit zohn 
35 Eiementen das letzto Element bedingt kornpi- 

liert wird, enthafien die beiden Syntaxbaumc 
Kopien des Unterbaums der ersten neun An- 
weisungen der Folgo. Diese Wiederholung ist 
naturlich sehr verschwenderisch. 
.to " In gleicher Weise ergibt sich beliebig viol 
Code, wenn die Schritte fur eine #endif-An- 
weisung in den Nachfolgern eines Verbin- 
dungsknotens duplizicrt werden. Dieser Code 
ist notig, um die syntaktischen Einheiten zu 
■is vervollstandigen, die innerhaib von #ifdef an- 

fangen. Anweisung S4 in Abbildung 1 ver- 
deutlicht diesen Fall. Die Kopie dieses Codes 
wurde den Teil, der bedingt kompiiiert v/ird. 
nur sehr ungenau darstellen. 
50 Diese und viele Probleme ergeben sich wegen 

der Wiederholungen, die durch eine baumartige 
Darsteilung erforderiich werden. Dies lafit sich 
durch diese Erfindung losen. indem man eine Dar- 
steliung wahlt, die auf Graphen basieri, die im 
55 weiteren Verlauf als abstrakte Syntaxgraphen 
(ASG) bezeichnet werden. Ansteile der Verdoppe- 
lung gemeinsamer Unterbaume. verweist man von 
mehreren Stellen aus auf eine gomeinsame Posi- 
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(ion. FIG 2 zeigt den abstrakten Syntaxgraphen fur 
das Programm von FIG 1. Dabei ist zu beachten, 
dafl der Verbindungsknoten Join eingefugl wurde, 
urn die Stelle zu markieren, an der die Parser- 
Prozeduren wieder zusammenlaufen. Die Nachfol- 
ger dieses Krtotens reprasentieren die beiden Half- 
ten der #ifdef-Anweisung. Die Knoten der Anwei- 
sungsfolge direkt Liber S1 und die Anweisung S4 
kommen in beiden Nachfoigern vor. Obwohl eine 
Darstellung in Form eines Graphen etwas schwieri- 
ger zu durchwandern ist, gibt sie die Struktur des 
ursprunglichen Programms exakt wieder. 

Die Erzeugung dieser Darstellung erfordert die 
Behandfung von drei Probiemen: 

1. Die Prozedur mufi einen Knoten fur die Ver- 
bin dung aufbauen und sicherstellen, da/3 alle 
Knoten, die Code aus der bedingten Kompilie- 
rung darsteilen, Nachfolger dieses Knotens sind. 

2. Es mussen Verweise auf die Knoten erzeugt 
werden, in denen der gemeinsame Code darge- 
stellt wird, bevor man bei einer #ifdef-Anwei- 
sung wieder zu den ursprunglichen Knoten zu- 
riickkehrt. 

3. Dasselbe ist fur Knoten zu bewerkstelligen, 
die den Code nach der #endif-Anweisung dar- 
steilen. 

Diese Problems werden mit Hilfe eines Werte- 
Stacks gelost. Jeder Eintrag auf dern Werte-Stack 
ist ein Zeiger auf einen Knoten im abstrakten Syn- 
taxgraphen. Findet wahrend des Parsens eine Re- 
duktion stall, wird die entsprechende Aktionsroutine 
ausgefuhrt. Diese Routine nimmt eine Reihe von 
EintrSgen vom Werte-Stack und erzeugt etnen neu- 
en Knoten, der die vom Stack heruntergeholten 
Zeiger enthalt. AnschlieBend wird ein Zeiger auf 
diesen Knoten auf den Werte-Stack gelegt. Diese 
Methode wird von LALR-Parsern standardma'/Jig 
unterstutzt. 

Das Anlegen des Verbindungsknotens Join an 
der richtigen Stelle liegt auflerhaib der Kriterien fur 
die Zusammenfuhrung von Parser-Prozeduren. Der 
Verbindungsknoten Join wird in einer Riicksprung- 
Routine erzeugt, die bei der Zusammenfuhrung 
zweier Parser-Prozeduren aufgerufen wird. Die 
obersten Eintrage des Werte-Stacks der beiden 
zusammengefiihrten Parser-Prozeduren verweisen 
auf Untergraphen, die den Code darsteilen, der im 
#if- b2w. #else-Abschnitt liegt. Alies, was unterhalb 
dieser Eintrage liegt, lag bereits vor, als die Parser- 
Prozeduren aufgespaiten wurden. Da sich die 
Parser-Prozeduren an dieser Stelle in identischen 
Zustanden befinden, mussen die Knotentypen am 
Ausgangspunkt dieser Unterbaume gleich sein. Die 
Knoten konnen durch einen einzigen Verbindungs- 
knoten Join ersetzt werden, der auf die Unterbau- 
me verweist. 

Die Verbindung der Knoten durch Verweise 
zum Darsteilen der gemeinsamen Code-Abschnitte 



vor einer #ffdef-Anweisung liegt ebenfalls aufier- 
halb der Parser-Prozedur. Da die Eintrage auf den 
Werts-Stacks nur Verweise auf Knoten im abstrak- 
ten Syntaxgraphen darstetien und selbst keine Kno- 
s ten sind, werden durch das Kopteren des Werte- 
Stacks wahrend der Aufspaltung einer Parser-Pro- 
zedur keine Kopien von Knoten angelegt. Es wer- 
den ledigSich Kopien der Knotenverweise erzeugt. 
Wenn also die Reduktionen in den abgespalienen 

w Parser-Prozeduren stattfinden. enthaiten die erstell- 
ten Knoten nur kopierte Verweise, und keine Ko- 
pien der Knoten selbst. 

Derselbe Vorgang fur die Knoten hunter der 
#endif-Anweisung gestaltet sich wesentlich schwie- 

75 riger. Die vorliegende Parser-Strategie unterstutzt 
dies nicht. Fur die Realisierung benotigt man eine 
Kommunikationsmoglichkeit zwischen den abge- 
spaltenen Parser-Prozeduren, damit Informationen 
tiber die Zustando ausgctauscht werden konnen. in 

so denen sich die Parser-Prozeduren befinden. Mo- 
montan ist dieses Problem noch nicht getost. Lctzt- 
lich wird em Graph erzeugt, indem die #endif- 
Anweisung auf den Verbindungsknoten Join des 
abstrakten Syntaxgraphen kopiert wird. Semantisch 

25 gesehen enfhaft der erzeugte Graph alle informa- 
tionen des ursprungSichen Programms: es ist je- 
doch eine platzsparendere Darstellung moglich. 

Ein weiteres Problem ergibt sich bei der Be- 
rucksichtigung der Praprozessor-lnformationen von 

30 Makrodefiniiionen in der Darstellung von C-Pro- 
grammen Es wSre wunschenswert, wenn man bei- 
de Formen eines Makros, vor und nach der Erset- 
zung des Aufrufs, im abstrakten Syntaxgraphen 
darsteilen kdnnte Dies ist aber nicht immer mog- 

35 lich, da das Ergebnis einer Makro-Ersetzung nicht 
notwendigerweise syntaktisch abgeschlossen sein 
muS, d.h. es mufi sich nicht unbedingt em Unter- 
baum des abstrakten Syntaxgraphen ergebert. Wir 
haben einen KompromiC enfwickelt. urn dieses Pro- 

40 biem zu losen. Der Anwender hat zwei Alternatives 
In der ersten Alternative werden die Abschmtte des 
abstrakten Syntaxgraphen. die sich aus der Erset- 
zung eines Makros ergeben. markiert. es wird aber 
nicht versucht. die Aufruf ohne Ersetzung darzu- 

45 stellen. Wenn der Anwender jedoch garanfieren 
kann, da/3 keine syntaktisch unvollstandigen Ma- 
kros vorkommen, wird derselbe Mechanismus ver- 
wendet, um die ersetzten und die nicht ersetzten 
Formen von Makros darzustellen, Ein eigener Par- 
se* ser erzeugt mit Hilfe der cpp-Grammatik einen 
Unterbaum fur die nicht ersetzte Form. Der Haupf- 
parser wird aufgespaiten und mit dem ersetzten 
Text versorgt. Anschliefiend wird mit ParseJom 
eine Zusammenfuhrung signalisiert. in der em Ver- 

55 bindungsknoten Join mit nur einem Nachfolger an- 
gelegt wird. Anschiiifiend wird der Unterbaum mit 
der nicht ersetzten Form des Makros emgebunden. 
Der Verbindungsknoten Join wird mit Attnbuten 
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versehen, die anzeigen, dafi es sich urn das Ergeb- 
nis eines Makro-Aufrufs handelt, und nicht urn eine 
bedingte Kompilierung. 

Die ubrigen Eigenschaften des C-Praprozes- 
sors, die noch dargesteilt werden mussen, wis 
^include, #define, Kommentare, usv/., werden 
durch Attribute der Knoten des Graphs behandelt. 
Da diese Eigenschaften an einer beliebigen Stelle 
im Programm auftreten konnen, ist es nicht mog- 
lich, sie in Form von Knoten innerhatb des abstrak- 
ten Syntaxgraphen darzustellen. Aus Platzgriinden 
taucht im Beispiel keine Obernahme einer Datei mit 
Hilfe dei #include-Anweisung auf. Da Include-Da- 
teien ubiicherweise fur Dekiarationen verwendot 
werden, wird Isdiglich die Information der Symbol- 
iabelle aus der Include-Datei ubemommen. 



Anspruche 

1. Verfahren fur die automatische Syntaxanalyse 
(Parsen) des Textes von Computer- Program- 
men in Kompilterern und entsprechenden Ein- 
richtungen, wobei der Text bedingte Kompilie- 
rungsanweisungen enthali, aus denen sich 
mehrere Versionen eines Programms aus ei- 
nem einzigen Text abielten, 
gekennzeichnet durch 

- Muttiplexen und Synchronisieren mehre- 
rer gleichzeitig aktiver Parser-Prozedu- 
ren, die einen gemeinsamen Eingabe- 
strom des Textes verarbeiten; 

- Abspalten einer neuen Parser-Prozedur 
beim Auftreten von bedingten Kompilie- 
rungsanweisungen im Eingabestrom, die 
anzeigen, daC direkt nachfoigende Einga- 
ben eine Variante aus einer Vietzahl von 
moglichen Programmvarianten darstel- 
len, als ParseFork- Operation; 

- Zusammenfuhren von zwei zuvor aufge- 
spaitenen Parser-Prozeduren, falls alle 
Kriterien fur eine Zusammenfuhrung et- 
fullt sind , ais ParseJoin-Operation, sowie 

- Festlegen der Reihenfolge der Shift- 
Reduklions-Operationen in einem LR- 
Treiber fur die miteinander synchronisier- 
ten Parser-Prozeduren. 

2. Verfahren nach Anspruch 1 , 
gekennzeichnet durch den Austausch einor 
Parser-Prozedur, die einem Verzweigungspfad 
der bedingten Kompilierungsanweisung zuge- 
ordnet ist, durch die Parser-Prozedur des an- 
deren Verzweigungspfads der bedingten Kom- 
pilierungsanweisung als ParseExchange-Ope- 
ration. 

3. Verfahren nach Anspruch 2, 



dadurch gekennzeichnet, dafi nach Auftreten 
einer bedingten Kompilierungsanweisung im 
Eingabe Strom eine neue Parser-Prozedur ab- 
gespalten wird und eine Kopie des aktuellen 

5 Parser-Status gespeichert wird, damit der Ein- 

gabestrom von mehr als einer Parser-Prozedur 
verarbeitet unci spater festgestellt werden 
kann, ob sich die beiden Parser-Prozeduren in 
einem Zustand befinden, in clem sie zusam- 

m mengefuhrt werden konnen. 

4. Verfahren nach Anspruch 3, 

dadurch gekennzeichnet, da/3 zwei zuvor 
aufgespaliene Parser-Prozeduren Reduktionen 
fs in heuristisch festgelegten Reihenfolge unter- 

zogen werden, damit die beiden Parser-Proze- 
duren mit der kleinstmoglichen Anzahl an 
Shift-Redukiions-Operationen miteinander ver- 
bunden werden konnen. 

20 

5. Verfahren nach Anspruch 4, 

dadurch gekennzeichnet, dap jede Parser- 
Prozedur einen Status-Stack und einen Werte- 
Siack besitzt, die miteinander synchronisiert 

25 sind und dafi, falls die zugohorige #endif- 

Anweisung angetroffen wird und beide aurge- 
spaltenen Parser-Prozeduren identisehe Zu- 
stande aufweisen sov/ie im Weite-Stack ge- 
speicherte Werte bei einer Zusammenfuhrung 

30 nicht verloren gehen, alle Zusammenfuhrungs- 

kriterien erfUIlt sind und sine Zusammenfuh- 
rung vollzogen wird, ohno da/3 Informationen 
verlorengehen. 

3S 6. Verfahren nach einem der Anspruche 1 bis 5, 
gekennzeichnet durch folgende Verfahrens- 
schritte: 

i. Solange verarbeitbare Teile des Textes 
als Token zur Eingabe verffJgbar sind: Aus- 
40 wahl des nachsten Tokens unci Wirksam- 

schalten aller Parser-Prozeduren, die von 
der Eingabe ausgeschlosscn warcn, so dafi 
das neue Token von diesen Parser-Proze- 
duren verarbeitet werden kann. 
45 ii. Solange eine Parser-Prozedur fur die Be- 

arbeitung der aktuellen Eingabe verfugbar 
ist, Aus wahl der nachsten vorfugbaren 
Parser-Prozedur fur die Verarbeitung des 
Tokens mit folgenden Operationen: 
so A. Wonn actio n[ C urState .token] =_ shift s, 

s auf den Status-Stack legen und diese 
Parser-Prozedur sotange von der Verar- 
beitung ausschlie/Jen, bis aile anderen 
Parser-Prozeduren das aktuelfe Token 
5S verarbeitet haben. 

B. Wenn actionfCurState.token] = reduc- 
tion A -> li, dann re duction A^>~P. durch- 
fuhren;Tn~dem 

8 
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1. bei jedem Grammatiksymbol im 
String B ein Element vom SLatus-Stack 
genommen wird, 

2. bei einer anstehenden Parser-Zu- 
sammenfuhrung und Erfuliung der Kri- 
terien fur eine Zusammenfuhrung der 
beiden belroffenen Parser-Prozeduren 
die beiden Parser-Prozeduren zusam- 
mengefuhrt werden und 

3. CurState auf GQto[CurSlate,A] ge- 
setzt und CurState auf den Stack ge- 
!egt wird. 

C. Wenn aciion[CurState,token] = ac- 
cept, ist die Parser-Prozedur abgeschlos- 
sen. 

7. Verfahren nach Anspruch 6, 
gekennzeichnet durch foigende Operation: 
Wenn action[CurStale,token] =_ error , wird die 
Parser-Prozedur verworfen. 

8. Verfahren nach einem der AnsprCiche 1 bis 7, 
dadurch gekennzeichnet, da/3 unter der Vor- 
aussetzung, da/3 

p und p" zwei aufgespaltene Parser-Prozedu- 
ren sind, 

f und f als Zeiger auf die oberste Position das 
Status-Stacks zcigon, der fCir beide Parser- 
Prozeduren zum Zeitpunkt der Spaltung ge- 
meinsam gilt, 

t und t' als laufende Zeiger auf die jeweilige 
Spitze der Status-Stacks beider Parser- Prozdu- 
ren zeigen, 

Sj, Sa ... s< ... s, den einen Status-Stack und 
s'i, s'2 ... s't ... sY den anderen Status-Stack 
beschreiben 

die Bedingungen fur die Zusammenfuhrung 
der beiden Parser-Prozeduren erfullt sind, 
wenn gilt: 

1. Die zugehorige #endif-Anweisung wurde 
verarbeitet. 

2. f = f 

3. Sf M = sVm 

4. t = f + 1 

5. f = V + 1 

9. Verfahren nach einem der Anspruche 1 bis 8, 
dadurch gekennzeichnet, da/3 die Parse- 
Fork-Operation durch die Kompiiierungsanwei- 
sungen #ifdef, #ifndef Oder #if als Token im 
Eingabestrom ausgelost wird, wobei der au- 
genblickliche Parser-Zustand einschlieSlich des 
Werte- und Status-Stack der Parser-Prozedur 
kopiert wird und der Eingabezeiger von alien 
Parser-prozeduren gemeinsam verwendet wird, 
und 

da/3 die ParseExchange-Operation durch die 
bedingten Kompilierungsanweisungen #else 



Oder #elif als Token im Eingabestrom ausge- 
lost wird, wobet die augenblicklich ausgefuhrte 
Parser-Prozedur ausgesetzt wird, wahrend die 
augenblicklich ausgesetzten Parser-Prozeduren 
5 aktiuiert und fur die Aufnahme von Token vor- 

bereitet werden. 

10. Verfahren nach Anspruch 9, 

dadurch gekennzeichnet, da/3 jede Opera- 
>o tion mit einer anwendungsspezifisehen 

Ruckspmng-Routine verbunden ist, die bei je- 
der Operation aufgerufen wird. 

11. Verfahren nach Anspruch 9 und 10, 

75 dadurch gekennzeichnet, da/3 die Operatio- 

nen ParseFork, ParseJoin und ParseEx- 
change vom LR-Treiber ausgefuhrt werden 
und da/S boi der Ausfuhrung einer ParseJoin- 
Opcration und Vorliegen zweier wegen nicht 

20 identtscher Zustande augenblicklich nicht zu- 

sammenfuhrbarer Parser-Prozeduren die Zu- 
sammenfuhrung aufgeschoben wird und meh- 
rere Parser-Prozeduren aktiv bleiben. bis die 
Parser-Prozeduren zusammengefijiirt werden 

26 konnen, wobei die Rucksprung-Routme solan- 

ge nicht aufgerufen wird, bis die Zusammen- 
fuhrung erfolgt. 

12. Verfahren nach einem der Anspruche 1 bis 11. 
30 dadurch gekennzeichnet, dafl eine Parser- 

Verwaltung den Eingabestrom des Programms 
multiplex! und bestimmt, welche Parser-Proze- 
dur durch den LR-Treiber laufen soil. 

35 13. Verfahren nach Anspruch 12. 

dadurch gekennzeichnet, dafi der Zustand 
der einzelnen Parser-Prozeduren in emer Vari- 
abien in der Parser-Verwaltung festgehalten 

40 

14. Verfahren nach Anspruch 13. 

dadurch gekennzeichnet, da/3 folgende Zu- 
stande auftreten konnen: 

- Active: Die Parser-Prozedur dari das ak- 
45 tuelle Token aus dem Eingabestrom ent- 

gegennehmen-. 

- BlockedOnlnput: Das aktuelie Token 
wurde von der Parser-Prozedur bereits 
erkannt, und es konnen kerne weiteren 

so Operationen durchgefuhrt werden kon- 

nen, da die anderen aktiven Parser-Pro- 
zeduren bereits darauf warten. das aktu- 
elie Token zu verarbeiten. 

- Sleeping: Eine Parser-Prozedur wurde 
55 ausgesetzt, da sie nichts mit dem aktuel- 

len Eingabestrom zu tun hat. weil eine 
Verzweigung einer bedingten Komptlie- 
rungsanweisung verarbeitet wird und die 
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artdere Verzweigung auf die entspre- 
chende #else- Oder #endif-Anweisung 
wartet. 
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© Verfahren filr die automatische Syntaxanalyse (Parsen) des Textes von Computer-Programmen in 
Kompilierern. 



© Zur Ermittlung und Darstellung der Struktur von 
Programmer!, die wie in C Praprozessor-Anweisun- 
gen und Erweiterungen gegenijber der abstrakten 
Syntaxbaum-Darstellung aufweisen, wird ein modifi- 
zierter Parser-Generator mit zugehoriger Parser-Ver- 
waitung verwendet, wobei mehrere Parser-Prozedu- 
ren denselben Eingabestrom vom Token verarbeiten 
und zusatzliche Operationen zum Abspalten neuer 
Parserprozeduren und zum Zusammenfuhren von 
aufgespaltenen Parser-Prozeduren sowie zum Aus- 



tausch einer Parser-Prozedur fur den 1 einen Zweig 
einer bedingten Kompilierungsanweisung durch die 
Parser-Prozeduren fur den anderen Verzweigungs- 
pfad beim Auftreten von vorgegebenen bedingten 
Kompilierungsanweisungen ausgefuhrt werden. Wel- 
che der Parser-Prozeduren jeweils durch den Pars- 
ergenerator laufen soil, besstimmt die Parserverwal- 
tung, wobei der jeweilige Statur der einzelnen 
Parser-Prozeduren in der Parse rverwaltung festge- 
halten wird. 
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